1. Technical Field of the Invention
The present invention relates generally to the field of wireless telecommunications and, more particularly, to a system and method for transmitting and receiving messages between first and second software components, such as, for example, application software and a software services component of a platform in a mobile terminal for a wireless telecommunications system.
2. Description of Related Art
Since cellular telecommunications systems were first introduced in the 1980s, mobile terminals (Mobile Stations) utilized in the systems have become increasingly more complex. Initially, mobile terminals were designed primarily to provide voice telephony services; i.e., to receive and transmit voice communications. In later years, mobile terminals were developed that also included the ability to transfer user data not related to that of a voice telephone call. Such user data included, for example, data to be transferred over a dial-up networking connection initiated via a personal computer (PC).
Currently, so-called “third generation” (3G) systems are being developed for future mobile telecommunications systems. 3G systems will combine high-speed Internet access with traditional voice communication, and will provide a user with access to Internet browsing, streaming audio/video, positioning, video conferencing and many other capabilities in addition to voice communication.
The Third Generation Partnership Project (3GPP) was established to ensure compatibility among the several 3G systems that are being developed around the world. The Universal Mobile Telephone System (UMTS) is being developed by 3GPP to provide a 3G system that includes terrestrial and satellite systems capable of delivering voice, data and multimedia anywhere in the world.
The drastically increased functionality that is being included in cellular telecommunications systems via the 3GPP standardization has placed substantial demands on the developers of mobile terminals to be used in the systems. This demand is exacerbated by the fact that a mobile terminal is a “resource scarce” environment that is limited in size, memory and power.
Traditionally, mobile terminal manufacturers have designed, fabricated and marketed substantially complete mobile terminal systems that include all the hardware and software needed for basic terminal operation as well as the hardware and software needed to provide the features and capabilities desired by the manufacturer or a particular user based on their perception of market needs. Such an approach does not provide the flexibility to quickly adapt to rapid changes in market demands or to satisfy the diverse requirements of multiple stakeholders.
Recognizing the inadequacies of traditional procedures for designing and fabricating mobile terminals, a mobile terminal platform assembly has been developed that includes a plurality of functionally complementary units of software and hardware that can be marketed as a unit to a plurality of users. Each user can then install, load, and run his own application software into the assembly to provide a tailored platform system for a mobile terminal that meets the user's own particular needs. The mobile terminal platform assembly and the platform system are described in detail in commonly assigned U.S. patent application Ser. Nos. 10/359,911 and 10/359,835, the disclosures of which are hereby incorporated by reference.
A platform system such as described above, wherein mobile terminal platform assembly software and application software are developed separately and then later combined by installing, loading, and running the application software in the mobile terminal platform assembly, requires that result messages originating from a service request, which may also include delivery of event information, be transmitted from software in the platform assembly to an application via an interface in the platform assembly. Such messages may be transmitted using either a stack/procedure-based approach (i.e., callback mode), or a serial-based approach (i.e., full message mode).
The callback mode is a simple and well-proven technique that allows an application to focus on application specific functionality and leave basic and complex mechanism-related handling to the platform or framework. The software developer has the possibility to route messages directly to a handler of the result (function/procedure/method). For example, the developer/user may initiate a user interface application where, e.g., a Window Manager passes messages holding information of the user interaction events or messages to well-defined handlers. The invocation of the user code is completely determined by the Window Manager. The value-added functionality is accessible or available to the developer, whereas the message loop and the freeing of messages are not viewable to the user. Thus, the developer is not required to route the different messages to dedicated parts of the program and the developer cannot degrade the system. Therefore, in callback mode, the application code has no control in terms of when, and in what order, to process a certain message. In some circumstances, the application may need to control the order in which messages are processed, or the time at which a specific message is processed (i.e., priority handling).
Accordingly, another technique, denoted the full message mode, may be utilized as an alternative to the callback mode. The full message mode queues messages at, for example, an application thread. The queued messages then await processing by the application. The queued messages may be processed in an ordered manner, such as in a FIFO technique, or the queued messages may be processed in parallel or in a prioritized manner. In this case, the application code has complete control of the message loop.
Current solutions, such as those incorporated into PalmOS and Brew environments, allow a user to use either the callback mode or the full message mode, but the user or application software is not free to choose the mode in which to receive incoming messages. The callback or full message mode is predetermined for the application.
There is, accordingly, a need for a message model that offers the user (application software) the choice of receiving messages either via the callback mode or the full message mode. The user may choose which message mode best suits the problem individually at each different instance.